<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Connection-oriented and connectionless transmissions',
	'<{subtitle}>' => 'Written in <span title="Communications and Networking">CS 2204</span> by <a href="https://y.st./">Alex Yst</a>, finalised on 2018-04-18',
	'<{copyright year}>' => '2018',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<h2>Connection-oriented transmissions</h2>
<p>
	Connection-oriented transmissions occur over an established connection through the network.
	This connection is set up before any payload-carrying packets can be sent, and when the connection is no longer needed, it&apos;s taken down and forgotten by the system (a7thson, 2003).
</p>
<h3>Advantages</h3>
<h4>Packets have a well-established order</h4>
<p>
	A connection is both a session and a route through the network.
	As the packets all travel the same path, their order is perfectly preserved (Dordal, 2014).
	The computer at the receiving end of the transmission has no difficulty in connecting the payloads of the packets to recover the full data being sent.
</p>
<h4>Less headers</h4>
<p>
	Once a connection is established, there&apos;s no need for certain information, such as the recipient&apos;s network address, to be transmitted with every packet.
	Leaving that information out lowers transmission overhead (Dordal, 2014), allowing a higher percentage of the packet&apos;s data to be payload data.
	Some minimal headers are still needed for keeping track of which session a packet belongs to, but the routers along the connection path keep track of the information necessary for packet delivery themselves.
</p>
<h4>Arrival confirmations</h4>
<p>
	Packets sent in a connection-oriented transmission are acknowledged as having arrived at their destination (Dordal, 2014).
	If this acknowledgement never reaches the sender of the initial packet, that sender can send it again.
	This means that lost packets are detected and retransmitted, so the message gets through reliably if it&apos;s possible to get through at all.
	(It&apos;s worth noting that in theory, a packet could arrive just fine and the acknowledgement be lost, which would be detected by the original sender as a lost packet.
	In this case, the receiver may receive the same packet twice, but the second copy can be thrown out after being re-acknowledged.)
</p>
<h4>Resource reservation</h4>
<p>
	A connection-oriented network is able to allocate resources to be used by a connection until that connection&apos;s termination, at which point the resources are free and can be reserved by a new connection.
	What this allows the network to do is reject the formation of new connections during busy points.
	If the network doesn&apos;t have the available resources to support a new connection, instead of the lines becoming congested, the new connection simply won&apos;t be established (Dordal, 2014) and the currently-active connections will be allowed to continue transmitting without degradation of speed or quality.
</p>
<h3>Disadvantages</h3>
<h4>Connection overhead</h4>
<p>
	As mentioned above, packets sent over an established connection don&apos;t cause as much network overhead in the form of large packet headers.
	However, each switch along the connection path must store a copy of the delivery information that can be looked up by the session identifier in the packet&apos;s smaller header (Dordal, 2014).
	Instead of this information being duplicated in every packet&apos;s header, it&apos;s instead duplicated in the session tables of each and every involved router.
	For smaller networks, this works out fine, but for larger networks, the tables become too large to be easily managed.
</p>
<h4>Only a single path is used</h4>
<p>
	Once a connection is established, it&apos;s path is set in stone.
	No matter how many packets the connection needs to carry, they&apos;ll all take the same route through the network.
	This leads to an underutilisation of resources, as even if several alternate routes are available that could deliver some of the packets in parallel, the packets will instead all wait in the same queues instead (Dordal, 2014).
</p>
<h4>Confirmation overhead</h4>
<p>
	While arrival confirmations are one of the biggest advantages of connection-oriented transmissions, they still generate a lot of overhead.
	For each packet received, the receiver must send a confirmation packet back to the sender (Dordal, 2014).
	While this ensures data arrival, it also uses transmission time that could otherwise be used instead for data packets.
</p>
<h3>Design issues</h3>
<p>
	I&apos;d love to say the storing of session information in the network switches is a design flaw, but it&apos;s a legitimate design decision. An alternative exists, but it&apos;s got its own flaws.
	The fact that only a single path is used through the network regardless of the availability of other resources in a large flaw in the system though.
	It creates a sort of artificial congestion, as any congestion on that particular path makes it appear that the entire network is congested, as no other path can be used for that particular connection.
	The confirmation overhead could be made a bit more efficient too; if a packet or its confirmation is lost, the packet must be resent from the beginning of the virtual circuit, no the the place in which the drop occurred.
</p>
<h2>Connectionless transmissions</h2>
<p>
	Connectionless transmissions are simply sent through the network in a completely stateless manner.
</p>
<h3>Advantages</h3>
<h4>No connection overhead</h4>
<p>
	Unlike connection-oriented transmissions, connectionless transmissions are stateless (Dordal, 2014).
	While switches involved in connection-oriented transmissions must store session information for each active connection, connectionless transmissions have no concept of connections, and doesn&apos;t have need to store any of this data.
</p>
<h4>Multiple paths may be used</h4>
<p>
	No one path through the network is decided-upon to use for the entirety of the connection, as there is no connection.
	Each packet is sent in isolation with no regards as to what path other packets from the same sender and intended for the same recipient are travelling along (Dordal, 2014).
	This means that each packet may travel a different path depending on congestion levels, and packets can be sent along multiple paths in parallel to speed the transmission.
</p>
<h4>No confirmation overhead</h4>
<p>
	No reply is sent to acknowledge the receipt of a packet.
	This leaves the lines open for more payload-carrying packets to be sent instead.
</p>
<h3>Disadvantages</h3>
<h4>Packets have no order</h4>
<p>
	As packets can travel along multiple paths, a packet may arrive before a packet that was sent before it (Dordal, 2014).
	In other words, this the arrival can&apos;t be counted on as a queue.
	The packets could arrive in any order and there&apos;s no way to ensure any packet arrives before or after any other packet.
</p>
<h4>More headers</h4>
<p>
	No connection is established, so the switches store no session information (Dordal, 2014).
	Because each packet is sent in isolation, each packet must contain all the information needed for delivery, such as the network address of the recipient.
</p>
<h4>No arrival confirmations</h4>
<p>
	Packets are sent, but there&apos;s no way to know if they actually reached their destination (Dordal, 2014).
</p>
<h4>No resource reservation</h4>
<p>
	In times of heavy network use, there&apos;s no way to reserve resources.
	The network can become slowed down by excess traffic that is allowed to enter the network.
	Even worse, switch queues can overfill, resulting in packets being dropped (Dordal, 2014).
	As mentioned above, there&apos;s no way to detect lost packets, compounding the problem.
</p>
<h3>Design issues</h3>
<p>
	Connectionless transmission has a number of disadvantages, but I wouldn&apos;t call most of them flaws in the design.
	Connectionless transmission is designed to be very simple, and as a result, it simply lacks many of the added features of connection-oriented transmission.
	Claiming these missing features are design flaws would be like claiming that the fact that your sock drawer doesn&apos;t pair your socks for you is a design flaw; the dresser is too simple for that.
	The one flaw I do see though is that transmissions can be lost along any hop on the network, and not even the nodes on either end of that hop will be aware of it.
</p>
<h2>Preference and solution</h2>
<p>
	Of the two transmission styles, I&apos;d have to say I prefer connection-oriented transmission for one simple reason: lost packets can be detected and resent.
	While this isn&apos;t necessary for all transmissions, it&apos;s vital for a great many.
	The issue of packets needing to be resent from the beginning of the circuit seems like it could easily be resolved as well.
	Instead of an acknowledgement being sent from the receiver back to the sender, the acknowledgement can be sent back from each node to the node before it at the time it receives the packet to pass onward.
	During successful transmission, this method would involve the same amount of network traffic as the current method employed today.
	After all, the acknowledgement sent back from the receiver to the sender must make the trip back making several hops to do so.
	My method would involve the same number of hops, though each hop would be a separate acknowledgement message.
	However, when packets get dropped, my method would prevent a lot of hops from being needed, as the resent message could be sent from the switch that last held the message instead of from the very beginning of the circuit.
</p>
<p>
	It&apos;s worth noting too that such a system could be added to a connectionless transmission to add reliability without an established connection being needed.
</p>
<div class="APA_references">
	<h2>References:</h2>
	<p>
		Dordal, P. L. (2014, March). 1 An Overview of Networks - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/intro.html"><code>https://intronetworks.cs.luc.edu/current/html/intro.html</code></a>
	</p>
	<p>
		Dordal, P. L. (2014, April). 3 Other LANs - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/otherLANs.html"><code>https://intronetworks.cs.luc.edu/current/html/otherLANs.html</code></a>
	</p>
	<p>
		a7thson. (2003, January 2). Connection-oriented and connectionless services - Everything2.com. Retrieved from https://everything2.com/index.pl?node_id=1409718<a href=""><code></code></a>
	</p>
</div>
END
);
